1. Field of the Invention
The invention relates to communication networks. In particular, the invention relates to controlling services in a packet data based communication network in a novel and improved way.
2. Description of the Related Art
Nowadays service providers of packet data based communication networks, e.g. Internet Protocol (IP) based communication networks like Internet and various wireless communication networks such as General Packet Radio Service (GPRS) enabled mobile communication networks, Wireless LAN networks, and Code Division Multiple Access (CDMA) based mobile communication networks, need to provide value-added services in their networks in order to attract private and corporate subscribers to their network. Many such services require introducing intermediate nodes via which packets are routed before routing them towards the eventual destination IP address. The intermediate nodes perform a variety of tasks, which may be associated with different protocol layers. Such intermediate nodes are also called proxies.
The various value-added services provided may be categorized into subscriber services and network services. Examples of the subscriber services include packet data based voice, email, content downloading, browsing, streaming and rich calls. The network services are offered by packet data based mobile communication networks to support the usage of subscriber services. These network services include e.g. rerouting, barring, accounting, content proxy services, content blocking services, firewall services, virus scanning services, antispam services, performance enhancement proxy services, Virtual Private Network (VPN) services, various Quality of Service (QoS) related services and various charging related services both for online and offline charging. Unless otherwise stated, in the following the term ‘service’ is used to refer to both subscriber and network services.
In the case of Differentiated Services (DiffServ) it is sufficient to process packets at IP layer to perform packet metering, marking, shaping and dropping. Differentiated Services are more closely defined in, for example, the IETF RFC 2475. In the case of Transmission Control Protocol (TCP) connection routing, packets must be processed at TCP layer. The purpose of TCP connection routing is, for example, to allocate servers from a server resource pool for TCP connection requests. Typically, such TCP connection requests are associated with Hypertext Transfer Protocol (HTTP) content requests. The HTTP is defined in the IETF RFC 2616. In the context of mobile networks TCP proxies are also used to enhance performance over a slow and unreliable link layer connections. In the case of an application layer proxy, multiple packets constituting an application layer message must be intercepted in an intermediate node. An application layer proxy comprises also the lower layers, that is, the IP layer and the TCP or UDP layer. Application layer proxies are used in a variety of services which may be specific to the application protocol. Examples of application protocols in which proxies are used are Hypertext Transfer Protocol (HTTP, IETF RFC 2616), Session Initiation Protocol (SIP, IETF RFC 2543) and Simple Mail Transfer Protocol (SMTP, IETF RFC 2821). Application layer proxies are also used as application level gateways which perform protocol adaptation between different application layer protocols.
In the case of HTTP examples of services applied are rerouting, barring, accounting and charging services. In rerouting services an HTTP GET operation specifying a given Uniform Resource Locator (URL) is redirected to a different URL so that the URL is rewritten. The actual domain name part in the URL may already have been translated into an IP address at the source node, so a new destination IP address must be written to the HTTP GET operation. In barring services the proxy intercepts and bars HTTP GET operations targeted to given URLs. In accounting and charging services the volume of HTTP traffic to and from a given server address may be counted, for example. The volume of traffic may be measured in terms of data volume, that is, the number of bytes, or number of requests and responses. In accounting and charging applications it is also necessary to match HTTP requests (for example, GET operation) with HTTP responses (for example, 200 OK response). The purpose is, for example, to avoid charging for requests for which no response is received. Therefore, the HTTP proxy must also maintain the state of the HTTP messaging.
In addition to those mentioned above, value-added services to be provided in packet data networks may include content proxy services, content blocking services, firewall services, virus scanning services, antispam services, performance enhancement proxy services, Virtual Private Network (VPN) services, various Quality of Service (QoS) related services and various charging related services.
In some cases proxies such as those mentioned above are implemented as separate actual network elements. However, providing a whole gamut of services with separate network elements for each type of service eventually becomes difficult and expensive. Therefore, in some cases several proxy functionalities may be implemented in a single physical network element as service entities. A network element that implements several services may need to have a wide variety of service entities. By a service entity is meant herein an intermediate functionality configured between a packet source and a packet destination, which participates in the providing of a given service for the packets or higher layer protocol data units transmitted therein between the source and the destination. In more elaborate cases the service entities implemented by a given network element may belong to different networks, which may be administered by different administrative authorities. Further, some of the service entities may be located outside of the original network element in a remote network element, for example, in cases where the processing involved requires special hardware or it is otherwise meaningful to distribute the functionality. In such a case a packet is first transferred from the original network element to the remote network element in order to render it to the processing associated with the remote service entity. Thereupon, it is transferred back to the original network element.
Usually, when a packet arrives to a network element providing multiple service entities pertaining to one or many services, the network element must decide which service entities should be applied for the packet, that is, which service entities the packet should traverse. For each service entity a decision must be made whether the service entity should handle the packet, that is, whether the packet should be passed to the service entity. The packet needs to go through several decision points to determine which service entities need to process the packet. The service entities needed depend on the service that needs to be rendered to the packet. During the traversal of the packet through multiple service entities, the decision point between two service entities may become very complex and time consuming. Furthermore, the same decision may need to be made repetitively to determine whether a packet needs to be passed to a given service entity or not.
Reference is now made to FIG. 1, which illustrates a prior art process of determining which particular service entities need to handle a given packet received at a network element. In FIG. 1 there is a network node 100, which provides local and remote service entities by means of which at least one service may be rendered to the packet. Network node 100 is, for example, a GPRS support node. Network node 100 comprises Service Entity 1, Service Entity 2 and Service Entity 4. Packets are also relayed to and from a remote Service Entity 3 operating in a remote network node 102. A remote service entity is in other words an out-of-the-box service entity. Network node 100 further comprises Decision Point 1, Decision Point 3, Decision Point 3 and Decision Point 4. Decision points 1, 2 and 4 are associated with Service Entities 1, 2 and 4. Decision Point 3 is associated with the remote Service Entity 3. A packet passed to the remote Service Entity 3 is illustrated with arrow 119 and a packet returned or sent by the remote Service Entity 3 is illustrated with arrow 120.
An IP packet received by network node 100 is represented by arrow 110. The IP packet is passed to Decision Point 1. Decision Point 1 determines based on, for example, IP layer header information, higher protocol layer header information within payload or other payload information in the IP packet whether the IP packet must be subjected to processing performed by Service Entity 1. If processing performed by Service Entity 1 is required for the IP packet, Decision Point 1 passes the IP packet to Service Entity 1 as illustrated with arrow 114. Otherwise, Decision Point 1 passes the IP packet to a next Decision Point 2 as illustrated with arrow 111. When Service Entity 1 has performed processing on the IP packet, Service Entity 1 passes it to Decision Point 2 as illustrated with arrow 115. In the same manner each Decision Point 1-4 of FIG. 1 in turn inspects the IP packet and makes the decision whether the IP packet is to be passed to the Service Entity associated with the Decision Point. When each Service Entity has processed the IP packet, it is passed by them to the next Decision Point.
As a result of processing performed by Service Entity 2 the IP packet may once again have to be subjected to inspection at Decision Point 1. This is illustrated with arrow 118, which represents the loop back to Decision Point 1. The IP packet may have been modified by Service Entity 2 in such a way that it is necessary to inspect whether Service Entity 1 should process it again. When the last Service Entity 4 has processed the IP packet, it is subjected to routing decisions for determining the next network element to which it must be sent. Subsequent IP packets received at network node 100 are subjected to similar processing through the chain of Decision Points and Service Entities.
The disadvantage of a solution such as the one illustrated in FIG. 1 is that a decision point between two adjacent service entities may become extremely complex and expensive to implement and maintain. Furthermore, same decisions may need to be made repetitively to determine whether a packet needs to be passed to a service entity or not. For example, if same higher layer protocol headers must be detected and parsed in a similar manner in several decision points, the performance of network node 100 is reduced significantly. Let us assume, for example, that Service Entities 1 and 3 are configured to act as HTTP proxies for any packets carrying HTTP GET operations requesting a URL which belongs to a given set of URLs. In this case Decision Points 1 and 3 must both comprise same functionality of scanning packets containing TCP and HTTP headers, parsing HTTP headers to determine the URL and then checking whether the requested URL belongs to the given set of URLs.
Additionally, configuration of new services to a network node such as network node 100 is complicated. The software in network node 100 must be updated to reflect the new service entities and the associated decision points that need to be added to the existing chain of service entities.
The aim of the invention disclosed herein is to alleviate the problems discussed hereinbefore and to introduce flexibility in the creation, modification and execution of service entity chains. The processing performance of value-added services in network nodes is improved by avoiding double processing associated with service determination, i.e. determination of required service entities for a value-added service.